Protocol offload processing is known. For example, an interface device (sometimes known as intelligent network interface circuitry or an “offload target”) may be provided to operate in coordination with a host, for protocol offload processing with a peer device across a network. For example, the protocol offload processing may be according to the Transmission Control Protocol (TCP) whereas communication across the network may be via high-speed Ethernet, such as 10 Gbps Ethernet. FIG. 1 illustrates an architecture of a system including a host, network interface circuitry including an offload target, and a peer configured for communication with the host according to a stateful protocol such as TCP/IP.
Furthermore, it is known that the protocol offload processing may be, for example, “partial offload” or “full offload.” For example, with “full offload,” the offload target handles all the phases of a connection. That is, in addition to handling the data transfer phase of a connection, the offload target is additionally at least responsible for establishing a connection, including handling retransmissions, if necessary, during connection establishment.
“Partial offload” has various flavors. Examples include the following:                offload target handles only the data transfer phase of a connection-oriented protocol, which for example might include processing to reorder the received packets when they are received out of order.        offload target handles only the data transfer phase and the connection teardown phase of a connection-oriented protocol.        offload target handles the “mainstream” part of the data transfer phase, deferring exceptions, such as out of order processing, to the host system.        
Partial offload solutions have been promulgated such as, for example, the “TCP Chimney” feature of recently released Vista operating system from Microsoft. Like conventional partial offload solutions, the TCP Chimney feature appears to be designed to retain full control over connection acceptance while, in addition, simplifying management of listening servers.
A listening server, for example, is used when a peer requests a connection to a local host, such as a TCP/IP connection at a specified IP address and port number. A listening server typically has an LIP, LP, FIP, and FP attribute, such that a listening server on the local host is listening for connect requests to local IP address LIP, at local port number LP, from a foreign IP address FIP, and from foreign port FP at the FIP. The FIP and FP fields for the listening server many times have “don't care values,” such that connect requests are accepted from any FP on any FIP. A listening server may, in addition, have a protocol attribute such as TCP, or SCTP (Stream Control Transfer Protocol), as the SCTP protocol and other connection oriented protocols use a similar listening server mechanism to receive connect requests.
The connect request is received by the listening server that then forwards the request to a connection manager that either accepts all connect requests, or that uses various criteria such as ACL (Access Control Lists) to either accept or reject a connect request.
FIG. 2 illustrates an example of an “active open” operation to open a TCP/IP connection between the host and the peer, according to the TCP Chimney architecture. At 201, the host stack sends an active open request to the peer via a SYN packet. At 202, the peer responds with a SYN/ACK. The host stack sends an ACK in response to the SYN/ACK. At this point, the connection has been established on the host stack.
At 204, the host stack initiates offload of the connection to the offload target. At 205, a data packet arrives from the peer after the host stack initiates the connection offload but before the connection has been set up on the offload target. The data packet is therefore sent to the host. At 206, the host stack receives the data packet. Detecting that the offload is in progress, the host stack retains the data packet.
At 207, the offloading is complete. At 208, the host stack forwards the data packet back to the offload target for processing. At 209, the offload target processes the packet and provides an acknowledgment back to the peer.
We now discuss how a control block may be configured in accordance with an example of an active open operation. An example of such a control block is shown immediately below:
CONST_STATE Flags= 0x0 RemotePort= 0xF3FB LocalPort= 0x46B4 SndWindScale= 0x0 RcvWindScale= 0x0 RemoteMss= 1460:0CACHED_STATE Flags= 0x2 InitialRcvWnd= 0 RcvIndicationSize= 0 KaProbeCount= 0 KaTimeout= 0x0 KaInterval= 0x0 MaxRT= 0x0 FlowLabel= 0x0 TtlOrHopLimit= 0x80 TosOrTrafficClass= 0x0 UserPriority= 0x0DELEGATED_STATE State= TcpConnectionSynSent Flags= 0x0 RcvNxt= 0x0 RcvWnd= 0x0 SndUna= 0x0 SndNxt= 0x0 SndMax= 0x0 SndWnd= 17520 MaxSndWnd= 0x0 SendWL1= 0x0 CWnd= 0xB68 SsThresh= 0xFFFFFFFF SRtt= 0x0 RttVar= 0x1E TsRecent= 0x0 TsRecentAge= 0x0 TsTime= 0x0 TotalRT= 0x0 DupAckCount= 0x0 SndWndProbeCount= 0x0 KeepAlive.ProbeCount= 0x0 KeepAlive.TimeoutDelta= 0x0 Retransmit.Count= 0x0 Retransmit.TimeoutDelta= 0xFFFFFFFF SendDataHead= 0x0 SendDataTail= 0x0 SendBacklogSize= 0x0 Buffered Data= 0x0 ReceiveBacklogSize= 0x0
In accordance with one example of an active open operation, a “constant state” portion of a connection control block is provided in a manner that it may otherwise be provided in a configuration that does not include an offload target. A “cached state” portion of the connection control block may be partly determined by the offload target. The delegated state portion may be partially filled in by the offload target when the connection establishment succeeds. It is noted that, prior to connection establishment succeeding, all send and receive sequence numbers are undefined and the TCP state is SYN_SENT. The offload target interprets such a control block as being for an offloaded active open.
In accordance with other conventional implementations, an active open operation is achieved in a full offload manner. That is, in essence, the host requests the offload target to establish and operate a connection. FIG. 3 illustrates an example of an active open operation, for a TCP/IP connection, being achieved in a full offload manner. At 301, the host stack provides an “initiate offload” request to the offload target. The “initiate offload” request may be more generally referred to an offload event indication. At 302, the offload target provides a SYN packet to the remote peer. It is noted that the offload target handles any SYN retransmission issues, if any. At 303, the peer responds with a SYN/ACK packet. At this point, the connection is established and the connection control block is populated on the offload target. At 304, the offload target provides an “initiate complete” indication back to the host stack.
At 305, the offload target provides an ACK packet to the peer, in response to the SYN/ACK packet provided from the peer. At 306 and 307, the offload target receives a data packet (306) and acknowledges the data packet (307).
FIG. 4 illustrates an example of a partial offload “passive open” operation to open a TCP/IP connection between the host and the peer, according to the TCP Chimney architecture. At 401, the host stack receives a passive open request from the peer via a SYN packet. At 402, the host stack responds with a SYN/ACK. At 403, the peer sends an ACK in response to the SYN/ACK. At this point, the connection has been established on the host stack.
At 404, a data packet arrives from the peer. Meanwhile, at 405, the host receives the ACK and initiates a connection offload to the offload target. At 406, the host stack receives the data packet before the connection has been set up on the offload target. Detecting that the offload operation is in progress, the host stack retains the data packet. At 407, the host stack receives a message from the offload target that the offload operation is complete.
At 408, the host stack forwards the data packet to the offload target for processing. At 409, the offload target processes the data packet and sends an ACK to the peer. At 410, the peer receives the ACK corresponding to receipt of the data packet by the host.
We now discuss how a control block may be configured in accordance with an example of a partial offload passive open operation such as described relative to FIG. 4. An example of such a control block is shown immediately below:
CONST_STATE Flags= 0x0 RemotePort= 0xF3FB LocalPort= 0x46B4 SndWindScale= 0x0 RcvWindScale= 0x0 RemoteMss= 1460:0CACHED_STATE Flags= 0x2 InitialRcvWnd= 0 RcvIndicationSize= 0 KaProbeCount= 0 KaTimeout= 0x0 KaInterval= 0x0 MaxRT= 0x0 FlowLabel= 0x0 TtlOrHopLimit= 0x80 TosOrTrafficClass= 0x0 UserPriority= 0x0DELEGATED_STATE State= TcpConnectionSynRcvd Flags= 0x0 RcvNxt= 0xA1CD RcvWnd= 0xFFFF SndUna= 0x0 SndNxt= 0x0 SndMax= 0x0 SndWnd= 17520 MaxSndWnd= 0xFFFF SendWL1= 0x0 CWnd= 0xB68 SsThresh= 0xFFFFFFFF SRtt= 0x0 RttVar= 0x1E TsRecent= 0x0 TsRecentAge= 0x0 TsTime= 0x0 TotalRT= 0x0 DupAckCount= 0x0 SndWndProbeCount= 0x0 KeepAlive.ProbeCount= 0x0 KeepAlive.TimeoutDelta= 0x0 Retransmit.Count= 0x0 Retransmit.TimeoutDelta= 0xFFFFFFFF SendDataHead= 0x0 SendDataTail= 0x0 SendBacklogSize= 0x0 Buffered Data= 0x0 ReceiveBacklogSize= 0x0
In accordance with one example of a passive open operation, a “constant state” portion of a connection control block is provided in a manner that it may otherwise be provided in a configuration that does not include an offload target. In addition, a “cached state” portion of the connection control block may also be provided in a manner that may otherwise be provided in a configuration that does not include an offload target.
The “delegated state” portion of the connection control block may be partially filled in by the offload target when the connection establishment succeeds. It is noted that, prior to connection establishment succeeding, all send and receive sequence numbers are undefined and the TCP state is SYN_RCVD. The offload target interprets such a control block as being for an offloaded passive open.
FIG. 5 illustrates an example of a full offload “passive open” operation to open a connection (in this case, a TCP/IP connection) between the host and the peer. At 501, the peer issues a passive open via a SYN packet. The offload target initiates a connection control block in the SYN_RCVD state and, also, provides the SYN packet to the host stack. At 502, the host stack provides an initiate offload indication to the offload target. Alternately, the indication may be an indication that the connection is not to be established.
At 503, based on the initiate offload indication, the offload target provides a SYN/ACK to the peer. Furthermore, at 503, the offload target deals with connection establishment issues such as SYN/ACK retransmission issues. At 504, the peer issues an ACK packet for the SYN/ACK packet. At 505, the peer sends a data packet. At 506, the offload target provides an “initiate complete” indication to the host stack. It is noted that the initiate complete indication may be temporally before or after the offload target receives the data packet (505). In any case, the offload target handles the data packet and, at 507, provides a corresponding ACK packet back to the peer.